「從 AI Prototype 邁向 Production-Ready 的過程中，服務 Lifecycle 與資源邊界的治理至關重要。將 FastAPI 服務從 Podman 容器遷移至原生 systemd system service，能有效解決服務重啟後無法自動啟動的痛點，並建立嚴格的 Memory Guardrail。」

先前，我們陸續重構了 Angelina Agent 的三階段分析 pipeline、Prompt 強制執行規則、後處理淨化、Telegram Byte-Safe 推播以及 Google Sheets 數據追蹤。

在完成軟體邏輯的重構後，我們面臨了部署架構層面的關鍵選擇。在舊版架構中，我們使用 Rootless Podman 容器運行 FastAPI 服務，但在長期運維中發現了兩個致命痛點：

  1. 重啟後服務無法自動拉起：當伺服器因系統更新或重啟後，Podman 容器偶爾無法自動啟動，導致每日盤後分析中途失聯。
  2. 記憶體邊界不可控：LLM Agent 在處理向量檢索與併發請求時，記憶體容易無預警膨脹，造成宿主機 OOM（Out of Memory）風險。

今天我們將解析最新進版中的部署架構重構——將 Angelina 遷移至 Linux 原生 systemd system service！

本篇重點摘要

1. 剖析從 Rootless Podman 遷移至 Native systemd 的核心動機與維運效益。
2. 逐行解析 /etc/systemd/system/angelina.service 原始配置文件。
3. 實作 MemoryMax=2G 資源邊界控管與 Restart=always 自動復原自我修復機制。

一、部署架構對比：Podman Container vs Native systemd

為了徹底解決服務穩定度與資源邊界問題，我們將部署架構從容器化調整為原生系統服務，以下為兩者的關鍵差異拆解：
1. 開機自動啟動與可靠度
(1) 舊版 (Rootless Podman Container)：依賴 Podman User Session 觸發，主機重啟或系統更新後，偶爾未自動拉起容器服務。
(2) 最新進版 (Native systemd Service)：深度整合 Linux multi-user.target，伺服器開機 100% 保證自動拉起服務。
2. 資源限制與護欄 (Resource Limits)
(1) 舊版 (Rootless Podman Container)：需要額外配置容器 cgroups 參數，管理與維運較分散。
(2) 最新進版 (Native systemd Service)：原生支援 MemoryMax=2G 設定，建立確定性的記憶體上限防禦，防止 OOM。
3. 環境變數管理 (Environment Management)
(1) 舊版 (Rootless Podman Container)：容器啟動指令傳遞變數較繁瑣，更新金鑰容易留存歷史紀錄。
(2) 最新進版 (Native systemd Service)：原生支援 EnvironmentFile=/opt/angelina/.env 集中隔離與權限管控。

  4. 維運與日誌監控 (Observability)
     (1) 舊版 (Rootless Podman Container)：需透過 podman logs 查詢，日誌與宿主系統互相隔離。
     (2) 最新進版 (Native systemd Service)：完全整合標準 Linux journalctl -u angelina.service 原生工具鏈。

二、angelina.service 原始配置文件深度解析

我們在 Linux 伺服器的 /etc/systemd/system/angelina.service 中部署了以下原生服務組態：

[Unit]
Description=Angelina AI Finance Agent
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=angelina
WorkingDirectory=/opt/angelina
EnvironmentFile=/opt/angelina/.env
ExecStart=/opt/angelina/venv/bin/uvicorn app.main:app --host 0.0.0.0 --port 8080
Restart=always
RestartSec=5
MemoryMax=2G

[Install]
WantedBy=multi-user.target

關鍵配置細節剖析：

1. 網路依賴管理 (After=network-online.target / Wants=network-online.target)：
   確保伺服器網路完全連線後才拉起服務，避免因網路未就緒導致無法呼叫 Gemini API 或 Telegram API。
2. 低權限帳號隔離 (User=angelina)：
   使用專屬低權限帳號 angelina 運行，避免使用 root 執行，建立資安隔離邊界。
3. 環境變數集中管理 (EnvironmentFile=/opt/angelina/.env)：
   將 Telegram Token、Gemini API Key 等敏感金鑰隔離在 /opt/angelina/.env 檔案中，權限設為 600，確保版控庫中不洩漏憑證。
4. 自動修復與降級重試 (Restart=always, RestartSec=5)：
   若 FastAPI 服務因未預期的 Exception 崩潰，systemd 會在 5 秒內自動拉起服務，提供強大的 Self-Healing 機制。
5. 記憶體護欄 (MemoryMax=2G)：
   將服務記憶體上限封頂在 2GB。當記憶體超過 2GB 時，Linux cgroup 會自動干預，防止單一服務拖垮整台伺服器。

三、原生維運指令與監控實務

遷移至 systemd 後，服務的管理完全回歸 Linux 標準運維生態：

# 1. 重新載入 systemd 服務組態
sudo systemctl daemon-reload

# 2. 啟動服務並設定開機自動啟動
sudo systemctl enable --now angelina.service

# 3. 檢查服務運行狀態與記憶體消耗
sudo systemctl status angelina.service

# 4. 即時查看運行日誌
journalctl -u angelina.service -f -n 100

四、今日總結

透過將 Angelina Agent 遷移至原生 systemd 託管，我們達成了：

1. 100% 穩定自啟動：徹底根絕了舊版容器在伺服器重啟後服務未自動啟動的噩夢。
2. 確定性資源防護：MemoryMax=2G 為系統提供了明確的記憶體安全防線。
3. 運維極簡化：完全相容 Linux 標準 systemctl 與 journalctl 工具 chain。

明日預告：【Day 21】敬請期待~（ ˙Ⱉ˙ ）